1. Technical Field
This invention relates to the general field of user interface automation, and particularly (though not exclusively) runtime graphical user interface automation.
2. Background Art
User interface automation involves the development of technical test scripts which will execute and which will allow an application to be navigated and tested in an automated way, i.e., with no user intervention. If the automation scripts are well written then errors/bugs will be automatically recorded so that an engineer can acknowledge and address these bugs when the automation scripts have run to completion. Once the bugs are fixed it is a common practice to execute the automation scripts again, thereby proving that the application being tested is bug free.
Automation scripts are commonly written so as to 1) significantly speed up the software testing process, 2) allow automation to run when engineers are away from the office (e.g., at night), and 3) develop test cases which are complete and comprehensive. Automation is therefore a useful tool/methodology for reducing costs of quality engineering and testing, as it speeds up the same activity that would otherwise be done manually.
One of the main problems/drawbacks with automation scripts is that they need to be heavily modified so as to execute on translated versions of an application (and it is common knowledge that testing on translated versions of the application accounts for over 80% of a corporation's worldwide testing effort). This process of modification (so that the automation can be run against translated versions of an application) is time consuming and error prone in a number of ways. Once the automation is developed it traditionally needs to be “re-engineered” to accommodate the characteristics of different language versions of the application. In particular, references that the automation makes to textual components on screen are invalid when the automation is executed on a translated version of the same application. Re-engineering implies fundamental structural changes to the automation to allow it to run on the translated versions of the application. Subsequent testing, revision and re-testing of the automation is also time consuming. Finally, when the automation is modified to cater for a subsequent version of the application (e.g. Version 2) the cycle of re-engineering, revision and re-testing needs to happen again. Therefore, the current industry methodology for developing automation results in a process which is time consuming and expensive when translated/language versions of the same application are considered. Because of this, few companies develop automation to run on translated versions of the application (i.e., it is generally written and designed for English versions of the application).
From U.S. Pat. No. 5,475,843 ('843 patent) there are known a system and methods for automated program testing which require predetermined, systematic and complex interception of the running application at run time. The level of interception is intrusive, and has the disadvantage of creating a high probability of compromising the natural execution of the application. In Quality Engineering terms, methods of automation are gauged on their effectiveness, and one measure is the level of interference for the running application being tested. The methods used in the '843 patent rely on an interception-based methodology or system, rather than allowing the application to run unhindered.
A second drawback to the methodology used in the '843 patent is that it cannot intercept and control the resolution and management of complex user interface control types (such as InfoBox panels in IBM® Notes™ and Smartsuite™ products, or a number of the more complex user interface classes in Sun Microsystems' J2EE™—Java™ 2 Platform, Enterprise Edition).
Further, in the '843 patent's methodology the application is centric, i.e., the interception of all application messages, events (keyboard, mouse, system), states, etc., is a pre-requisite to success. Such a model once again interferes with the natural execution of the application. This gives rise to quality and engineering considerations which can undermine the true value of the automation being run.
Finally, the methodology used in the '843 patent encourages a level of abstraction which can potentially take some degree of control from the script writer. In this regard the script writer is somewhat dependent on the methodology and characteristics of the '843 patent's interception and event handling engine. This limits the degree of control that the script writer can have in the '843 patent's natural test abstraction development methodology.
In summary, the '843 patent's automated testing solution behaves in a way which encourages interference and interception of the running application. The '843 patent relies on the specific interception of the running application to achieve its goals, and relies on the need to write ATUs (Application Translation Units).
A need therefore exists for a system and method for language-neutral runtime user interface automation wherein the abovementioned disadvantage(s) may be alleviated.